1. Field of the Invention
The present invention relates to client/server computing, and deals more particularly with techniques for more efficiently processing multiframe data for transmission to a client workstation, where the transmitted data may be rendered, e.g., displayed in one or more frames of a multiframe graphical user interface display on the workstation.
2. Reservation of Copyright
A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.
3. Description of the Related Art
The popularity of client/server computing has increased tremendously in recent years, due in large part to growing business and consumer use of the public Internet and the subset thereof known as the “World Wide Web” (or simply “Web”). Other types of client/server computing environments, such as corporate intranets and extranets, are also increasingly popular. As solutions providers focus on delivering improved Web-based computing, many of the solutions which are developed are adaptable to other client/server computing environments. Thus, references herein to the Internet and Web are for purposes of illustration and not of limitation. (Furthermore, the terms “Internet”, “Web”, and “World Wide Web” are used interchangeably herein.)
Millions of people use the Internet on a daily basis, whether for their personal enjoyment or for business purposes or both. As consumers of electronic information and business services, people now have easy access to sources on a global level. When a human user is the content requester, delays or inefficiencies in returning responses may have a very negative impact on user satisfaction, even causing the users to switch to alternative sources. Delivering requested content quickly and efficiently is therefore critical to user satisfaction.
Most modem computing applications render their displayable output using a graphical user interface, or “GUI”. In a client/server computing environment such as the Internet, client software known as a “browser” is typically responsible for requesting content from a server application and for rendering the information sent by the server in response. Commonly, the displayed information is formatted as a Web page, where the layout of the Web page is defined using a markup language such as Hypertext Markup Language (“HTML”).
The layout of a Web page may be defined as a single frame, or as multiple frames. The term “multiframe” is used herein to refer to Web pages that contain multiple frames. It should be noted, however, that use of multiple frames is not limited to Web pages: any type of GUI window may be divided into multiple frames. Thus, discussions herein of multiframe “pages” are provided for purposes of illustration but not of limitation, and these discussions should be construed as including the more general multiframe windows.
One common example of a multiframe display is a file manager window. A file manager window shows the directory structure of the files or objects stored on a storage device of a computer. Typically, the structure is presented using a hierarchical tree view in the leftmost part of a window, and the stored files or objects for a selected level of the hierarchy are presented in the rightmost part of the window. An example of this type of presentation is the Windows® Explorer application from Microsoft Corporation. (“Windows” is a registered trademark of Microsoft Corporation.) File manager windows are not typically designed as client/server applications. However, if an application of this type is used in a client/server environment, the directory structure may pertain to a remote file system. When the user selects an entry from the displayed hierarchy, the client application may cause the user's browser to send a request to a remote server, asking for details pertaining to that level of the directory (such as a list of the individual files and/or subdirectories of that level).
Another common example where a multiframe layout is used is in the display of publications that have a table of contents, where the table of contents is displayed in the leftmost part of a window and, when an entry in this table of contents is selected, the corresponding text is displayed in the rightmost window. In a client/server environment, the table of contents may be transmitted to the client browser initially for rendering in a Web page, and the user's selection of an entry from this display typically sends a new content request to the server from which the publication text is available. In this manner, the text can be incrementally retrieved.
These are examples of multiframe windows where the content of one frame is operably linked to another one of the frames. That is, the contents of the rightmost pane depend on a selection made by the user from the directory structure hierarchy or table of contents in the leftmost pane. This linking relationship among the frames of a multiframe window is not required in the general case, however, and many examples exist where the multiple frames simply provide a convenient organizational approach. For example, a company might design its Web presence so that all of the company's Web pages have a common structure, with a common heading and footer on each page. FIG. 1A shows an abstract example of this layout. In this example, the heading 100 and footer 120 areas of the Web pages may be designed as separate frames, with another frame (or perhaps multiple frames) being used for the body 110 of the pages. FIG. 1B shows a similar example, where a navigation frame 130 has been added. This navigation frame may be used to control what is displayed in the body of the page, using operable links between frames as described above with reference to file manager and table of contents frames.
Browser support for multiframe Web pages was made mandatory in Version 4.0 of HTML, and a vast number of multiframe pages have been created and deployed. While use of multiframe pages has a number of advantages, including design of content-rich Web pages, drawbacks exist in the manner in which these pages are redrawn (e.g., to refresh or revise the displayed content) on the user's workstation. In particular, when a browser requests a refresh for one frame of a multiframe page, there is no mechanism in the prior art for sending a response that supplies the requested content as well as content for only those other frames that are in need of redrawing. That is, while current technologies permit updating a single one of the frames or all of the frames, there is no prior art mechanism that provides for refreshing a subset of the frames.
It may be desirable to redraw or refresh a frame because of changes to previously-displayed data; because of asynchronous events out-of-band of the user's request (that is, changes that are not related to the user's request); in order to keep multiple frames synchronized (such as in the file manager and table of contents window examples, where selection of an entry from the leftmost window should be followed by a refreshing of the rightmost window); and so forth. (Hereinafter, the terms “refresh”, “redraw”, and “reload” are used synonymously when referring to redisplaying a frame or page.) Prior art mechanisms are for the server to respond by sending only the frame specifically requested by the browser, or to respond by sending the complete multiframe page including all of its contained frames (using, for example, procedural scripting code generated by the server to force reloading of the entire page); or, client-side logic such as an applet or special markup language syntax could be used.
As an example of using logic such as an applet on the client side, code may be written to iteratively poll the server for each frame in turn, thereby reloading each frame repeatedly (without regard to whether the frames need to be redrawn). As an example of using special markup language syntax to cause the client to request frame refreshes, the “META” tag construct may be used within a page encoded in HTML to specify a refresh interval and a Uniform Resource Locator (“URL”) identifying the content to be refreshed. For example, the following META tag causes the rendering to be refreshed every 10 time units with content retrieved from the URL www.ibm.com:<META HTTP−EQUIV=“Refresh” CONTENT=“10; URL=http://www.ibm.com/”>
Each of these prior art approaches has drawbacks. When using the META tag markup language construct, if the URL that is specified to be refreshed is the page that is currently rendered at the workstation, the iterative refresh causes a continuous polling affect—i.e., retrievals that repeat at the refresh interval. (META tag syntax may be programmatically generated at the server to force this type of reloading, or in some cases, the META tag syntax may be statically defined in the page.)
If the server sends an entire multiframe page, even though some frames have not changed, this is an inefficient use of resources and may waste a considerable amount of network bandwidth. In addition, the time required to refresh the page may increase considerably, and “browser frame flashing” may occur due to multiple reloads of the same frame. Conversely, if the server sends only the requested frame regardless of other frames that may need refreshing, the displayed GUI may present stale or invalid information. A client-side polling solution introduces significant overhead on the client, leads to an inefficient use of server resources and network bandwidth, and causes unnecessary visual flicker as frames arc repeatedly reloaded (many of which may have had no updates).
Accordingly, what is needed are improved techniques for processing multiframe data.